An “object graph” is a collection of related objects which are represented in forms including binary, text, XML (“Extensible Markup Language”), etc. FIG. 1 illustrates a class diagram. The class diagram (3) represents the classes that may be present in a given object graph, attributes associated with the classes, the relationships between the classes, and associated accessors. Further, the class diagram (3) encapsulates the class definitions necessary to create the class. For example, the class diagram in FIG. 1 contains a Purchase—Order class (2) with a PURCHASE—ORDER—ID attribute. The Purchase—Order class (2) is related to a LineItem class (4) with a one-to-many relationship. Further, the Purchase—Order class (2) contains an accessor, LineItems, for the relationship to the LineItem class (4). The LineItem class (4) contains an LINEITEM—ID attribute, a QUANTITY attribute, and a DISCOUNT attribute. Further, the LineItem class (4) contains an accessor, Product, for the relationship to the Product class (6), and an accessor, Purchase—Order, for the relationship to the Purchase—Order class (2). The LineItem class (4) is related to a Product class (6) with a one-to-one relationship. The Product class (6) contains a PRODUCT—ID attribute, a NAME attribute, and a PRICE attribute.
The class diagram (3), illustrated in FIG. 1, may be used to create numerous object graphs that conform to the class diagram. For example, FIG. 2 illustrates an exemplary object graph (8) that conforms to the class diagram (3 in FIG. 1). The object graph (8) contains a Purchase—Order—Object—1 (10) that contains a PURCHASE—ORDER—ID attribute. The Purchase—Order—Object—1 (10) is related to three LineItem objects 11, 12, and 13. As specified by the class diagram (3), each LineItem object (11, 12, and 13) contains a LINEITEM—ID attribute, a QUANTITY attribute and a DISCOUNT attribute. Each LineItem object (11, 12, and 13) is related to one Product object. For example, LineItem—Object—1 (13) is related to Product—Object—1 (14), LineItem—Object—2 (12) is related to Product—Object—2 (15), and LineItem—Object—3 (11) is related to Product—Object—2 (15). As specified by the class diagram (3), each Product object (14, 15) contains a PRODUCT—ID attribute, a NAME attribute, and a PRICE attribute. The Purchase—Order—Object—1 (10) may be called the root of the object graph (8) because the Purchase—Order—Object—1 (10) (explicitly or implicitly) references all objects in the object graph (8) and is the entry point into the object graph (8).
In the context of distributed applications, data are typically present as distributed objects, and the relationships between the objects are typically represented by object references. Each distributed object is associated with a datum that uniquely distinguishes this instance of data among all others in the distributed application. In many applications, the datum is a value within a distributed object, such as a “primary key,” that defines the distributed objects identity. For example, in FIG. 2, the Purchase—Order—Object—1 (10) may be uniquely identified by the Purchase—Order—ID1.
In distributed applications, is it important that when a particular distributed object is used within a transaction (i.e., a discrete activity within a computer system; transactions are usually associated with database management, order entry, and other online systems), that the distributed object contains the most current/updated information.
One prior art solution to ensuring that the most current/updated information is present in the distributed object prior to initiating a transaction is Java™ Remote Method Invocation (RMI). RMI provides a means to transport the distributed object between two distributed processes (e.g., a client and a server), and create a new copy of the distributed object if an instance of the distributed object is currently present on the receiving process. The new copy of the distributed object has the same object identity as the instance of the distributed object currently present on the receiving process. The new copy of the distributed object is commonly referred to in the art as an “Alias.” Additionally, in the event that a particular transaction requires an object graph (i.e., a number of related distributed objects), each object is requested individually. Further, if a requested distributed object is part of an object graph but is not the root distributed object, then the portion of an object graph required to reach the requested distributed object, starting at the root distributed object, is retrieved.
FIG. 3 illustrates a prior method for ensuring data coherency in a distributed system. Object Graph A (19) includes a root distributed object (16). The root distributed object (16) references two child distributed objects (18, 20). One child distributed object (20) additionally references two other child distributed objects (22, 24). Consider the case where an application on a separate process requires distributed objects 16 and 20. If RMI is used, then the following events occurs: (i) Response 1 instantiates a first alias root distributed object (16′); (ii) Response 2 instantiates a first alias child distributed object (18′).
If a subsequent request requires child distributed objects (18), (20), and (22), the following events will occur: (i) Response 3 instantiates a second alias root distributed object (16″) for distributed object 16; (ii) Response 4 instantiates a second alias child distributed object (18″) for distributed object 18; (iii) Response 5 instantiates a first alias distributed object (20′) for distributed object 20; and (iv) Response 6 instantiates a first alias distributed object (22′) for distributed object 22.
The result of the two concurrent application requests is two object graphs (Object Graph B (21), Object Graph C (23)) located on the receiver. Further, there are multiple copies (i.e., aliases) of distributed objects having the same object identity, e.g., distributed object 18 has two aliases (18′, 18″) on the receiver. Thus, if two independent changes are made to each of the aliases (18′, 18″), the update may be partial, or produce unexpected results.
For example, having two aliases of a same Employee distributed object in an application may lead to a case where the application modifies a “phone number” attribute of a first Employee alias distributed object. The application then stores the modifications made to the Employee alias distributed object to a database. The application subsequently modifies a “last name” attribute of the second Employee alias distributed object. The application then stores the modifications made to the second Employee alias distributed object to the database. As a result, the old “phone number” of the Employee is stored to a database.